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On receipt of a request for a communication session over a 
communications network, such as an Internet Protocol com- 
munications network, a path for the session is established. In 
a preferred example the communications network is an 
MPLS network and the method uses a modified version of 
the SIP messaging protocol. Bandwidth along a chosen path 
is reserved and a messaging protocol such as CR-LDP used 
to establish this reserved path for the communication ses- 
sion. Internet protocol and MPLS communications networks 
typically only support uni-directional flows. Several meth- 
ods for establishing bi-directional communication sessions 
over internet protocol communications networks that use 
MPLS connections are described. This is particularly useful 
for telephony applications using internet protocol commu- 
nications networks. In a preferred example, the established 
connection provides a guaranteed level of quality of service. 
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ESTABLISHING BI-DIRECTIONAL Multi Protocol Label Switching (MPLS) is a standard 

COMMUNICATION SESSIONS ACROSS A messaging protocol that is suitable for carrying Internet 

COMMUNICATIONS NETWORK Protocol traffic over communications networks such as 

Asynchronous Transfer Mode (ATM) networks and Frame 
5 Relay networks. 

BACKGROUND OF THE INVENTION t • . k An r t u i * u n » i 

Constraint-based Routing Label Distnbution Protocol 

1. Field of the Invention (CR-LDP) is also a standard messaging protocol (CR-LDP 
This invention relates to a method of establishing a is defined in Internet Draft: draft-ietf-mpls-cr-ldp-01.txt) 

bi-directional communication session between two end- that is suitable for use with communications networks that 
points in a communications network, and in particular but ^° ^^e MPLS. Mechanisms such as CR-LDP allow MPLS the 

not limited to, situations where it is required to provide a ability to set-up paths between two endpoints over a list of 

guaranteed quality of service for the connection. The inven- routers, where these paths have ATM-like traffic require- 

tion also relates to a communications network within which ments. However, there is no well-defined mechanism for the 

this method is implemented and ako to a computer program choice of the routers in this path that makes full use of the 

for controlling a communications network in order to imple- ATM-like traffic parameters. The only existing mechanism 

ment the method. (QOSPF Quality of Service Open Shortest Path First) allows 

2. Description of the Prior Art °°^y ^ advertised router speed and con- 

r , ^t, , *L*i gestion. In tandem, QOSPF is unable to make the fullest use 

One factor that must be taken into account durmg design t t r^n * i * j * -i j * *c 

r . , - 41. * <r *u *• fi * of CR-LDP as it cannot make use of the detailed traffic 

of communications systems is that of the time taken to j • *• j • /-m t r>n -.u j j . -i j 

. . . . T-u- L ij u L * descriptions used in CR-LDP; neither canit provide detailed 

estabhsh a communication session. This should be as short . - ^ * n ' ^^o^tT . . . 

as possible in order that customers are not deterred from information. As well as this QOSPF is not able to 

using the communications service and for appUcations in ^^^^^ [ connection over a suggested route, 

which communication sessions must be established without Another problem mvolves setting up bi-directional com- 

^Ql^y munications sessions over a communications network such 

, 1 ^ ^ . . . ^. . . as an internet protocol communications network. Telephone 

The time taken to estabhsh a communication session is a , . ... u ^ . i u . i 

, . , ... , , 1* f networks such as public switched telephone networks pro- 
particular issue when providmg a guaranteed quality of -j j j- . j . . n* ^ j 
^ . r * -- i? * *^ vide dedicated connections between a calling party and a 
service for transmission of internet protocol traffic. Quality „ , ^ . .- ^- i -.u i ^ j j.i. 

r . • ' ^ ^ c ^ \ • J called party that are bi-directional, with equal bandwidth 

01 service is an important tactor; customers require a good j i j r * r u *u \- ti 

V, r • f ; . . -H i- and guaranteed quality of service for both parties. However, 

quality of service for message transmission especially for an „ , , , , j , • . i . • 

^ I 1- L J r • J • mternet protocol and data communications networks typi- 

real-time applications such as video conferencing and voice, n . j j- . j ... 

A 11 .u- ™ ♦ „ 1 1 1 f cally do not provide dedicated connections that are 

As well as this many customers require a particular level of • . .i c 

V* r • ; u * J -r V. r ■ bi-directional m this way. This presents a problem for 

quality or service to be guaranteed: if quality of service . .-..i, . ^ 

J , _ ■ 1 r J. • • • • » * J situations in which telephony type applications are required 

drops below a certain level and transmission is interrupted or . , , j - . . . i ■ . i 

. L * i_i • L . using data and internet protocol communications networks, 

noisy this may be acceptable m some situations but unac- ^5 i • * * . i • * i 

/. , / Tc 1 1 1 £ 1 ^t r . For example, mternet protocol communications networks 

cep tab le m others. If particular levels of quahty of service , xnnr ■ . i * ■ n i 

^ , * J .V • • .-11 J \ A such as MPLS communications networks typically only 

can be guaranteed this IS particularly advantageous. A num- , . . li- 

, c ■■ / . J support uni-directional flows. When establishmg a connec- 

ber of approaches to provision of guaranteed quahty of .. .. . . - i l ■ 

r . ' ' e ■ * * * 1 * tion between two terminals over such a communications 

service for transmission oi internet protocol traffic are now . i - *i_ ^ * * * j 

J u J J *u *i . * u u network, It IS therefore necessary to semp separate forward 

descnbed and the time taken to establish such connections /n j . i . . . .. . . • i 

discussed backward paths between those two terminals. 

One approach that has been used is to prioritise individual " .^f ^^'^l^}y 5° ""jjf.^J; Ihe present invention to 

transmissions that are sent over the network. For example, a P'°^'<'* » °^ establishmg a bi-direcuonal commti- 

system known as "DifiBcrv" allows messages to be marked '°''P°/f \ communica- 

to indicate their priority. Nodes in a communications net- 45 "'T ' " °' 

work are then arranged to process high priority messages """'^ °^ P^blems noted above, 

first. This enables high priority messages to be processed SUMMARY OF THE INVENTION 

quickly but it does not provide a guaranteed level of quality ^ , , ^ , , , 

of service. Also a certain amount of processing time is , P^^her benefits and advantages of the mvenUon vyiU 

necessarily taken up in determining the highest priority 50 ^J^Tl fP"*".^ * consideration of the following 

message at a given node and this can lead to increases in the descnpUon ^ven with reference to the accompa- 

time taken to set up a communications session. "y^S drawings, which specify and show preferred embodi- 

... u u u . u J -j^u ments of the mvention. 
Another approach has been to reserve bandwidth over a 

particular route in a communications network. However, According to a first aspect of the present invention there 

systems that use this approach (for example RSVP Resource 55 ^ Provided a method of establishing a bi-directional com- 

reSerVation Protocol) typically are poor at implementing mumcation session between a first endpoint and a second 

aggregation mechaoisms^for example they cannot easily endpomt in a communications network, said method com- 

combine a number of separate sessions over the same route, prising the steps of: 

each must have its own reservation. Another shortcoming is (0 sending a communication from said second endpoint to 

that they also typically only allow the called party to reserve 60 said first endpoint to determine a path between said 

bandwidth that is required to host a communication session, second and said first endpoints; 

This docs not allow the calling party to specify their require- (ii) sending a first message along said path in order to set 

ments and this is problematic, especially because the calling up a first label mapping along said path, for use over 

party is typically the party which incurs costs for a call. Also, said path in a forward direction; and 

the time taken to set up reservations is often significant and 65 (iii) sending a second message along said path in order to 

can introduce delays in the time taken to establish a com- set up a second label mapping along said path, for use 

munications session. over said path in a reverse direction. 
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A corresponding communications network is provided 
comprising at least two endpoints between which it is 
desired to establish a bi-directional communication session, 
said communications network comprising: 

(i) a determiner arranged to determine a path between said 5 
second and said first endpoints by sending a commu- 
nication from said second endpoint to said first end- 
point; 

(ii) a processor arranged to send a first message along said 
path in order to set up a first label mapping along said 
path, for use over said path in a forward direction; and 

(iii) a processor arranged to send a second message along 
said path in order to set up a second label mapping 
along said path, for use over said path in a reverse 
direction. 

A corresponding computer program is provided stored on 
a computer readable medium said computer program being 
arranged to control said communications network such that: 

(i) a communication is sent from said second endpoint to 
said first endpoint to determine a path between said 
second and said first endpoints; 

(ii) a first message is sent along said path in order to set 
up a first label mapping along said path, for use over 
said path in a forward direction; and 

(iii) a second message is sent along said path in order to 25 
set up a second label mapping along said path, for use 
over said path in a reverse direction. 

This provides the advantage that a bi-directional commu- 
nications session is established between two endpoints in a 
communications network. This enables telephony applica- 30 
tions to be provided over a communications network such as 
an internet protocol communications network. In this case, 
the forward and reverse paths correspond and have the same 
bandwidth and quality of service provisions. 

In a preferred embodiment of the method described 35 
immediately above, said steps (ii) and (iii) of sending 
messages in order to set up label mappings occur substan- 
tially concurrently. This provides the advantage that the time 
taken to establish the bi-directional communication session 
is reduced. 40 

In a preferred embodiment a commimications session is 
established which has a guaranteed quality of service. 
Switched virtual circuit equivalency is effectively given for 
a communications network which can be an internet proto- 
col based communications network such as an MPLS net- 45 
work. 

Preferably, said communications network comprises a 
plurality of nodes connected together by links and said 
method further comprises the step of configuring the com- 
munications network such that the links between a first 50 
plurality of nodes are of a pre-determined capacity such that 
in use each of said links between the first plurality of nodes 
is capable of sustaining a plurality of separate communica- 
tion sessions. By provisioning the communications network 
in this way high capacity routes which act as "motorways" ss 
are created. By using these high capacity routes, the topol- 
ogy information required to implement the method is 
reduced. This simphfies the method and makes it faster to 
operate. 

According to another aspect of the present invention there 60 
is provided a method of establishing a bi-directional com- 
munication session between a first endpoint and a second 
endpoint in a communications network, said method com- 
prising the steps of: 

(i) sending a communication from said first endpoint to 65 
said second endpoint to determine a path between said 
endpoints; 



(ii) sending a message along said path in order to set up 
a first label mapping along said path, for use over said 
path in a forward direction; and also to set up a second 
label mapping along said path, for use over said path in 
a reverse direction. 
A corresponding communications network is provided 
comprising at least two endpoints between which it is 
desired to establish a bi-directional communication session, 
said communications network comprising: 

(i) a determiner arranged to determine a path between said 
endpoints by sending a communication from said first 
endpoint to said second endpoint; and 

(ii) a processor arranged to send a message along said path 
in order to set up a first label mapping along said path, 
for use over said path in a forward direction; and also 
to set up a second label mapping along said path, for 
use over said path in a reverse direction. 

A corresponding computer program is provided stored on 
a computer readable medium said computer program being 
arranged to control said communications network such that: 

(i) a communication is sent from said first endpoint to said 
second endpoint to determine a path between said 
endpoints; and 

(ii) a message is sent along said path in order to set up a 
first label mapping along said path, for use over said 
path in a forward direction; and also to set up a second 
label mapping along said path, for use over said path in 
a reverse direction. 

This provides the advantage that a bi-directional commu- 
nication session is set up quickly and effectively. The 
forward and reverse paths correspond and have the same 
bandwidth. 

According to another aspect of the present invention there 
is provided a communications network comprising at least 
two endpoints between which it is desired to establish a 
bi-directional communication session, said communications 
network comprising: 

(i) a processor arranged to establish a first uni-directional 
communication session between the endpoints in a 
forward direction; and 

(ii) a second processor arranged to establish a second 
uni-directional communication session between the 
endpoints in a reverse direction; and wherein said steps 
(i) and (ii) of establishing uni-directional communica- 
tion sessions take place substantially concurrently. 

A corresponding computer program is provided stored on 
a computer readable medium said computer program being 
arranged to control said communications network such that: 

(i) a first uni-directional communication session is estab- 
lished between the endpoints in a forward direction; 

(ii) a second uni-directional communication session is 
established between the endpoints in a reverse direc- 
tion; and such that said steps (i) and (ii) of establishing 
uni-directional communication sessions take place sub- 
stantially concurrently. 

This provides the advantage that the first and second 
communication sessions are not necessarily corresponding 
and may take different paths. This is especially usefiil when 
a uni-directional error occurs in the communications net- 
work. By arranging for the two uni-directional sessions to be 
formed concurrently, setup time is reduced. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a schematic diagram of a communications 
network. 

FIG. 2 is a flow diagram of the process of dynamic label 5 
switch path addition. 

FIG. 3 is a flow diagram of basic SIP operation with a 
proxy. 

FIG. 4 is a flow diagram showing use of a record -route 
header to track a route. 10 

FIG. 5 is a flow diagram showing forking with non- 
explicit abstract nodes. 

FIG. 6 is a flow diagram illustrating the process of 
forming a path element from a record-route header 

FIG. 7 illustrates a basic COPS model. 

FIG. 8 is a flow diagram illustrating COPS messaging. 

FIG. 9 is a flow diagram illustrating CR -LDP path set-up. 

FIG. 10 is a flow diagram illustrating signalling during 
set-up of a communication session. 

FIG. 11 is a schematic diagram illustrating advertisement 
of labels by label switch routers. 

FIG. 12 is a schematic diagram of the process of label 
propagation. 25 

FIG. 13 shows details of a COPS messaging process. 

FIG. 14 shows details of an LDP messaging process. 

FIG. 15 is a schematic diagram of the communications 
network of FIG. 1 with call servers. 

FIG. 16 is a schematic diagram of a first method of 
establishing a bi-directional communication session over the 
communications network of FIG. 15. 

FIG. 17 is a schematic diagram of a second method of 
estabhshing a bi-directional communication session over the 35 
communications network of FIG. 15. 

FIG. 18 is a schematic diagram of a third method of 
establishing a bi-directional communication session over the 
communications network of FIG, 15. 

FIG. 19 is a schematic diagram of a process for estab- 
lishing a mapping using the COPS protocol. 

FIG. 20 is a schematic diagram of a fourth method of 
establishing a bi-directional communication session over the 
communications network of FIG. 15. 

45 

DETAILED DESCRIPTION OF THE 
INVENTION 

Embodiments of the present invention are described 
below by way of example only. These examples represent 50 
the best ways of putting the invention into practice that are 
currently known to the Applicant although they are not the 
only ways in which this could be achieved. 

The term "bidirectional communication session" is used 
to refer to a period of communication over a communica- 55 
tions network thai involves transfer of information from a 
calling party to a called party and vice versa. The bidirec- 
tional communication session uses either a single two-way 
communication path or a forward communication path and 
a reverse communication path. go 

Pending U.S. patent application Ser. No. 09/345,059, now 
pending, also assigned to Nortel Networks Corporation, 
describes a method of establishing a connection between 
two endpoints in an internet protocol communications 
network, to provide a guaranteed level of quality of service. 65 
The contents of U.S. patent application Ser. No. 09/345,069, 
now pending, are incorporated herein by reference. 
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Although the method described in U.S. Ser No. 09/345, 
069, now pending, is in general effective, under some 
circumstances the time taken to establish such a connection 
is considerable, for example, for large communications 
networks such as carrier grade networks. Also, although the 
method described in U.S. Ser. No. 09/345,069, now pending, 
enables bi-directional communications session to be set-up, 
the resulting bi-directional communication sessions are not 
always optimally arranged for some situations. 

FIG. 1 is a schematic diagram of a communications 
network. Afirst endpoint 10 is connected to another endpoint 

11 via a communications network which comprises a plu- 
rality of nodes that are connected by links. These nodes 
include three abstract nodes 12, 13, 14 and many other nodes 
which are not shown individuaUy but which are represented 
by cloud shapes 15, 16 between the abstract nodes. These 
cloud shapes 17, 18 are intended to represent parts of the 
communications network which in one embodiment is an 
MPLS network. The cloud shapes 17, 18, nodes 12, 13, 14 
and endpoints 10, 11 comprise a physical layer of the 
communications network: 

Links 17, 18 are provided and these connect the abstract 
nodes 12, 13, 14 in series. Links 19, 20 are also provided to 
connect each endpoint 10, 11 to an abstract node and thus 
form a path or tunnel between the endpoints. However, this 
path from the first endpoint 10, via link 19 to abstract node 

12 which is connected in series to abstract nodes 13 and 14, 
and then via link 20 to the second endpoint 11, is only one 
of many possible paths over the communications network 
which connect the two endpoints 10, 11. These other paths 
are not explicitly shown in FIG. 1 but are intended to be 
represented by the presence of clouds 15, 16. The links 17, 
18, 19, 20 also form part of the physical layer of the 
communications network. 

Data or messages which are transmitted over the com- 
munications network can be thought of as comprising two 
types. First, customer data or messages such as video 
signals, voice signals or email messages and second, control 
data or messages. This control data functions to help manage 
the communications network; for example, control messages 
may comprise signals broadcast by a node in the commu- 
nications network to advertise its presence or its failure. The 
method of using the control messages is defined by the type 
of messaging protocol(s) used. 

In a preferred embodiment of the present invention, the 
MPLS standard messaging protocol is used in conjunction 
with the CR-LDP messaging protocol to help manage the 
communications network comprising the endpoints 10, 11, 
the abstract nodes 12, 13, 14, the clouds of nodes 15, 16 and 
the links between these. However, CR-LDP, while able to 
make quality of service reservations across known paths, is 
unable to determine these paths itself. In the present inven- 
tion additional components and messaging protocols are 
provided, for example, in order to determine and reserve 
guaranteed quality of service for particular connections for 
particular paths over the network. 

These additional components comprise an administrative 
server 35, admission managers 30, 31 and connection man- 
agers 32, 33, 34 and together these components form a 
management layer of the communications network. The 
admission managers 30, 31 and connection managers 32, 33, 
34 are referred to collectively as "management nodes". The 
additional messaging protocols include the standard Com- 
mon Open Policy Service (COPS) messaging protocol and a 
modified version of the standard IETF SIP (Session Initia- 
tion Protocol) RFC2543 protocol although these are all 
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examples of preferred messaging protocols; any suitable terminal accessed by the user is connected. Means is pro- 
messaging protocols may be used. The modified version of vided to determine passible paths for the required connec- 
SIP is designed to work in conjunction with COPS, CR-LDP tion together with measures of preference for these possible 
and MPLS, although it could be designed to work with paths. The measures of preference (for example, ranks) are 
similar messaging protocols to perform the same function. 5 determined on the basis of factors such as traffic levels in the 
This modified version of SIP will hereinafter be referred to network, length of path, and available capacities. One path 
as "SIP++". is chosen on the basis of the measures of preference. For 
In a preferred example, once a connection has been example, a path with the highest rank may be chosen and 
established using the method of the present invention, mes- reserved for the requested communication session. This 
sages are transmitted over that connection using a protocol gives a reserved path which can be used to provide a 
that involves labels. Each message or packet contains a guaranteed quality of service for a particular communication 
header with a label and each abstract node contains a session. Any suitable measure of preference such as a score, 
mapping which is a type of routing table. Using a label an percentage value or rank may be used, 
abstract node is able to determine which next neighbour In an embodiment of the invention a ranking mechanism 
abstract node to forward the packet or message to. The is used to select from the set of suitable paths, the route a 
mapping details, for received labels, which label should be new session will use to traverse an MPLS network. This set 
given to the message or packet when it is forwarded by the of paths and their ranking varies with network load, 
abstract node TTiat is, when a message or packet is received ^^^.^ ^^^^^ ^^^^^^^ ^^^^ 

Z^tZ H 'hT h^t'^h ' I . choosing between possible paths an advertising mechanism 

m the mappmg and determmes which label the packet . r. , t.- u n ■ .l • 

should now be |iven and hence where the packet should be 20 ^ P^^^^^^^ ^^^^^^ ^"^^^^^^ ^ ^ ? T"'''"'^' . 
forwarded next. The packet is then issued with the new label to gam mformation about traffic levels, topology of 
according to the mapping and forwarded by the abstract ^^^^^'^^ ^nfonnation can then be 
node. In order for this method to enable messages or packets ^ ^^^P decision about which path to choose, 
to be successfully transmitted between two specified advertisenient mechanism allows the system to choose 
endpoints, appropriate label mappings must be set up at the 25 ^^^^^^ ^^^^ suited to the session being established. Two 
abstract nodes involved. In the method of U.S. Ser. No. methods are proposed: explicit registration or by passively 
09/345,069, now pending, this is achieved after the SIP++ piggybacking information on path setup messages. The rate 
process is complete, using the CR-LDP protocol. That is, the of advertisement is a function of the rate of session set-up. 
SIP++ process is first used to determine a preferred path As well as an advertising mechanism, in order to reduce 
between two endpoints which will provide a guaranteed 3Q the complexity of choosing a path, a mechanism is provided 
quality of service. Information about this path is then given whereby an overlay network is configured to provide a set of 
to the physical layer and using the CR-LDP protocol an high capacity routes across the MPLS clouds which function 
actual connection is established along the chosen path. This as "trunk" routes or "motorways". An arrangement is then 
means that two effectively separate processes occur in series. made that communication sessions are preferably estab- 
In the present invention the label mappings are achieved in 35 lished using these pre-determined high capacity routes. This 
a different manner which enables the processes of choosing helps to reduce the topology information needed to establish 
a suitable path and establishing a communication session a path across a communications network. By using a con- 
over that path to be integrated rather than carried out in strained set of paths between the routers that comprise the 
series. MPLS network, the set of routes is constrained to reduce the 
In one example, Switch Virtual Circuit (SVC) admission 40 total topology information needed to route across the net- 
control equivalency is provided with guaranteed quality of work. 

service on an MPLS or similar communications network. An Referring again to FIG. 1, it can be seen that the admis- 

S VC is a path over a communications network between two sion managers 30, 31 and the connection managers 32, 33, 

endpoints which is effectively dedicated for a particular 34 as well as the administrative server 35 are depicted above 

communication session. These SVCs may be used to carry 45 the MPLS network. The admission managers, connection 

one or more communication sessions. managers and administrative server can be though of as a 

In the method of U.S. Ser. No. 09/345,069, now pending, "management layer" of the communications network, 

two main stages were involved. The first stage involved However, this layer is not physically independent from the 

selection of a path between the two endpoints using the rest of the communications network. For example, the 

SIP++ protocol. This SIP++ stage took place in the man- 50 SIP++ protocol control messages may be transmitted over 

agement layer of the communications network and involved the same physical links as the user information during 

propagation of control messages in at least one whole round communication sessions. 

trip between the two endpoints. Once this stage was Each endpoint 10, 11 is associated with an admission 

completed, the second stage of using the CR-LDP protocol manager 30, 31 and each abstract node 12, 13, 14 is 

to establish a communication session over the selected path 55 associated with a connection manager 32, 33, 34. As indi- 

(selected in the SIP++ stage) took place. This second, cated in FIG. 1, communication between the endpoints and 

CR-LDP stage also involved propagation of control mes- their associated admission managers and between the 

sages in at least one whole round trip between the two abstract nodes and their associated connection managers is 

endpoints. Because of this, the time taken to establish a carried out using the COPS protocol. Also, communication 

connection using the method of U.S. Ser. No. 09/345,069, 60 between the administrative server 35 and the admission 

now pending, involved at least two round trip delays. As the managers 30, 31 or abstract nodes 12, 13, 14 takes place 

communications network scales, a single round trip takes a using the COPS protocol. The way in which this is achieved 

considerable length of time and for carrier grade networks, using the COPS protocol is described in more detail below, 

the delay becomes a real problem when using the method of However, communication between the admission managers 

U.S. Ser. No. 09/345,069, now pending. 55 and connection managers takes place using SIP-I-+. 

When a user requests a connection for a communication The characteristics of some of the components of the 

session this request is passed to an endpoint to which a communications network are now described: 
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Abstract Nodes 30, 31 

Abstract nodes are a concept introduced by the CR-LDP 
protocol and represent one or more label switch routers 
(LSRs) which are conaccted together by links. By using a 
description equivalent to a subnet mask a whole group of s 
LSRs can be referred to. A subnet mask is an Internet 
Protocol (IP) mechanism used to define a group of IP nodes 
by only using the first n bits of their 32-bit IP addresses, 
where n is less than 32. The abstract nodes run the CR-LDP 
protocol and remain unaware of the SIP++ protocol running lO 
between admission managers and connection managers. 
Each abstract node may be directly configured by the 
Administrative Server, which may instruct an abstract node 
to establish a path to another particular abstract node. In the 
case where a CR-LDP network is used this path is referred 15 
to as a label switch path (LSP). SIP++ or any other suitable 
messaging protocol used provides a means of determining 
which of the label switch routers in an abstract node a path 
should be routed through. 

By using abstract nodes when selecting path candidates 20 
for a new session it is possible to be presented with a set of 
diverse routes. This provides the advantage that different 
routes over the network can be utilised and this is especially 
helpful if it is required to "spread load" over the network and 
if problems occur in localised regions of the network. 25 
Endpoints 10, 11 

An endpoint is any node in the communications network 
through which a user may request a communication session 
on the communications network. For example, in the case 
that an MPLS communications network is used an endpoint 30 
can be any MPLS device; either an MPLS enabled terminal 
or a router at the edge of the network. New communication 
sessions requested by an endpoint are sent to an admission 
manager that is associated with the endpoint. That admission 
manager then uses the SIP++ protocol and a path for the 35 
requested session is determined and reserved in order to 
guarantee the requested quality of service. Once the admis- 
sion manager has completed this task, the user request is 
validated and the validation communicated to the endpoint 
using the COPS protocol. Together with the validation, 40 
details of the chosen, reserved path are provided to the 
endpoint together with an identifier for the reserved path. If 
the request for a new session is granted, the endpoint runs 
the CR-LDP protocol using the exact same parameters that 
were used in the COPS request for a communication session 45 
together with the details of the chosen, reserved path. The 
CR-LDP protocol then establishes a path for the communi- 
cation session according to the standard CR-LDP method 
described below. Each endpoint is therefore effectively 
unaware of the SIP++ protocol running between the admis- so 
sion managers and connection managers. 
Admission Managers 30, 31 

Each admission manager is responsible for maintaining 
network topology information and using this to select a route 
across the network. When an admission manager receives a 55 
request for a communication session from an endpoint 10, 11 
it issues a plurality of path requests, which in a preferred 
example of the S1P++ protocol are referred to as INVITE 
messages. These path requests are control messages whose 
function is to request and determine possible paths between 60 
the required endpoints. In order to issue these path requests 
effectively, an admission manager needs to maintain accu- 
rate topological information about at least part of the com- 
munications network. Route advertisements are broadcast 
by entities in the communications network and an admission 65 
manager processes all the route advertisements it receives. 
This enables the admission manager to build up a map of all 
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the reachable nodes on the MPLS network and their avail- 
abiUty over time. An admission manager also monitors the 
bandwidth of connections to edge abstract nodes for the 
endpoint EP that it is associated with. (An edge abstract node 
is an abstract node that is positioned towards the edge of a 
communications network.) In this way an admission man- 
ager effectively provides admission control to the commu- 
nication network. Communication between an admission 
manager and its associated endpoint is via an interface such 
as a COPS interface. An interface to the administrative 
server 35 is also provided, which may be a COPS interface. 
This allows endpoints to request new tunnels or paths (for 
example new "trunk" routes) in the communications net- 
work such as an MPLS network. An admission manager is 
also arranged to respond to INVITE messages issued by 
other admission managers. This is described in more detail 
below. 

Connection Managers 

Each connection manager is associated with an abstract 
node and as described above an abstract node may comprise 
one or more Label Switch Routers LSRs. However, it is not 
essential for all label switch routers to be associated with a 
connection manager. 

Connections from these label switch routers to other 
abstract nodes are termed "label switch paths" (LSPs). Each 
connection manager monitors the bandwidth used in each of 
the label switch paths that emanate from the label switch 
router (or group of label switch routers) which it is associ- 
ated with (or managing). It also is responsible for advertising 
the level of congestion in these label switch paths to other 
administrative elements (such as other connection managers 
and admission managers) on a slow but regular basis. 

A cormection manager also keeps a record of the desti- 
nation abstract node for each of the label switch paths that 
it is monitoring. This information is also advertised by the 
connection manager. A connection manager also uses a 
COPS interface from the abstract node it is monitoring to 
allow registration of new label switch paths or a change in 
parameters of an existing label switch path. 
Administrative Server 

An administrative server 35 is used to provision paths in 
the communications network upon initialisation. For 
example, this involves establishing the label switch paths 
that the SIP++ protocol routes over. It is also used to change 
the characteristics of an existing path or introduce a new 
one. Although pictured as a single entity in FIG. 1, an 
administrative server 35 may take the form of multiple 
servers that administer their local area. 

An Administrative Server is able to communicate directly 
with any label switch router in a 'known' abstract node. It 
uses CR-LDP over this interface to provision high capacity 
label switch paths between these label switch routers via any 
number of intermediate label switch routers. Typically this 
will be through label switch routers with no associated 
connection manager, though this need not necessarily be the 
case. An administrative server has a much more detailed 
view of the topology of the intermediate MPLS network 
than the endpoints attached to it. (The intermediate MPLS 
network being that part of the communications network 
which is not local to the endpoints.) By pre-provisioning 
label switch paths of high capacity the administrative server 
constrains the number of possible routes between two end- 
points for a proposed communication session of a given 
capacity. This reduces the level of detail needed to make 
routing decisions. Such pre-provisioned label switch paths 
are referred to as "tunnels". 

In a preferred embodiment, when the communications 
network is first established, it sets up a network of tunnels 
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in the physical layer. These tunnels are subsequently regis- by the destination endpoint 302 to the originating endpoint 

lered with the management layer. That is, information about 301. If the INVITE is not accepted an error response is sent 

the source, destination and capacity of each tunnel is made in place of the 200 OK message. Once a 200 OK message 

known to the management layer. Each management node is received by an originating endpoint an ACK message is 

makes a record of the tunnels which originate or terminate 5 returned to acknowledge receipt of the 200 OK message, 

at the abstract node associated with that management node. This completes the call set-up. 

These tunnels are each uni-directional. However, in one SIP++ Tear Down Method 

embodiment, the tunnels are established such that equal ^he tear down method involves either endpoint in a 

sized tunnels exist in either direction between two label communications path terminatmg a call by issuing a BYE 

switch routers. That is, if an LSR is used in the path to an lo to the other endpoint 

endpoint, for every tunnel that terminates on that LSR, a ^^^H -^'^^7 , ■ . n . . 

^ , 1 . -J J r roTi ■ *u This method mvolves for example, endpoint B 302 start- 

correspondmg tunnel is provided from that l^R m the ^ ^ endpoint A 301 and Oien deciding not 

opposite direction. , , , to make this call after all. In this situation, endpoint B is able 

An Admmistrauve Server may also add new paths or ^ CANCEL message to endpoint A. 

change the characteristics of an exisUng path dunng the 15 jhe method of establishing a path for a communication 

operation of the network. This may either be initiated by the session with a guaranteed quality of service is now described 

network provider or via a request mechanism which is now together with an overview of the SIP++ method. Full details 

described. of SIP++ are described later. 

Request Mechanism When a COPS Request is received at an admission 

The Administrative Server 35 has a COPS interface to all 20 manager (requesting a path for a communication session), 

the admission managers at the edge of the network. This then providing admission is granted by the admission 

interface is used by those admission managers to request manager, one or more INVITE messages are sent out by the 

new high capacity label switch paths across the MPLS admission manager. The SIP++ INVITE message extends 

network, or to request a change in the capacity of an existing the standard SIP INVITE message to include a new message 

LSP 25 body type. Each INVITE message contains a description of 

FIG. 2 shows the process of requesting a new LSP. Either the requirements for the desired communication session. For 

an Endpoint 10 or an Admission Manager 35 issues a example, the trafBc characteristics which are used to estab- 

Request for a new route between two Abstract Nodes 12, 13 lish the path by CR-LDP. A path description is contained 

in the MPLS network. This is responded to by the Admin- within this new body to find a route across the MPLS 

istrative Server, with the acceptance situation being illus- 30 network that the new session could use. For example, the 

trated in FIG. 2. The Administrative Server now signals to path description can be a list of nodes which must be visited 

one of the specified abstract nodes ANl, 12 that it should in sequence to cross the network and reach the required 

set-up a path to the other abstract node AN2, 13. In the case endpoint. Some of the nodes may be unknown and repre- 

that the abstract nodes represent a group of label switch scnted as wildcards in the list. Each potential path is also 

routers, the administrative server specifies a particular label 35 assigned a rank which indicates the admission manager's 

switch router within each abstract node. preference for the route. 

The first abstract node 12 then registers the requested new For a given INVITE message, the path description is 

path and its characteristics with its Connection Manager 32. examined and the first reachable abstract node in the list 

This is achieved by issuing a COPS Request message over identified. The INVITE message is then sent to the connec- 

the COPS interface. The connection manager 32 does not 40 tion manager associated with that reachable abstract node, 

refuse this Request under normal operation and issues a This is repeated for each INVITE message issued by the 

COPS Decision message to this effect. Once a Decision is admission manager. 

received by the first abstract node 12, this abstract node When a connection manager receives an INVITE 

proceeds to use CR-LDP to establish the connection to the message, it examines the information about the session 

other specified abstract node. Once the new route is 45 requirements and next abstract node to see if it has a path to 

established, the connection manager 32 begins to advertise that abstract node and if it can accommodate the new 

its presence and the new route can be used immediately in session. There may be more than one path depending on how 

the path for a new session. well defined the abstract node is (for example, if the next 

SIP++ abstract node is represented in the path description by a 

A simpfified SIP++ messaging diagram is provided in 50 wildcard). If the answer is yes to both questions, it adds the 

FIG. 3, with a brief explanation of the role of each message. explicit address (such as an IP address) of the abstract node 

These messages are similar to those of SIP but the contents that it is associated with to the INVITE message. An 

of the messages are modified as compared to SIP. Vertical identifier for the connection manager itself is also added to 

lines 301 and 302 in FIG. 3 represent two endpoints between the INVITE message. This information is added to a route - 

which a proxy is located, which is represented a vertical line 55 record header field of the INVITE message. 

303. Messages are sent between these endpoints and the The connection manager then makes a temporary reser- 

proxy as indicated by the arrows between the vertical lines. vation for the session and forwards the INVITE message to 

SIP++ Registration Method the next abstract node in the path description. (If there is 

The registration method involves an endpoint, such as more than one abstract node at the next stage of the path 

endpoint B represented by vertical line 302, sending its 60 description, the INVITE message is "forked" as described 

internet protocol address to another endpoint, such as end below.) If there are insufficient resources or there is no label 

point A represented by vertical line 301. switch path to the next abstract node in the path description, 

SIP++ Call Set-up Method the connection manager will respond with an error message. 

The call-set up method involves an INVITE message This process is repeated until the INVITE messages reach 

being sent from an originating endpoint 301 to the destina- 65 the destination endpoint. 

tion endpoint 302. If this INVITE is accepted by the The destination endpoint waits for and collates the incom- 

destination endpoint 302 a so called 200 OK message is sent ing INVITE messages. When these INVITE messages were 
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issued by the originating admission nnanager, they were each endpoint 1201. The next stage of the SIP++ process involves 

assigned a rank by that admission manager. This rank sending back a 200 OK response from the second or 

indicates the favourability of a particular path and is scored destination endpoint 1201 to the origmating endpoint 1202. 

based on how congested the network appears to the origi- During this 200 OK response stage, advertised labels are 

nating admission manager. The rank or other measure of 5 chosen in such a way that a label mapping is established at 

preference is also determined on the basis of factors such as each LSR. Then once the 200 OK response reaches the 

the suitability of the returned path to the type of session originating admission manager 1203, label mappings have 

being established based on, for example, the latency of the been established at each LSR along the route. Because the 

path when establishing a real-time session. The admission labels are selected during the 200 OK response stage, which 

manager associated with the receiving endpoint now assigns lO is an upstream process, the labels have to be selected in such 

its own rank to the paths specified in the Record-Route a manner that they can later be used for the required 

hcaderofeachreceivedlNVITEmessage. For each path, the downstream communication session. This is achieved as 

rank from the originating admission manager and from the described below, 

receiving admission manager is combined in any suitable When an abstract node advertises a label (see 1205 in 

way, for example by addition, convolution or multiplication, is FIG. 11), information about that label reaches and is stored 

The path and associated INVITE message with the highest or cached at the management node 1204 that is associated 

scoring rank is then chosen, with the "downstream" end of the tunnel. For example, as 

As described above, each management node contains a shown in FIG. U, labels advertised by endpoint 1201 are 

record of any tunnels that originate or terminate at an stored at admission manager 1204 rather than at connection 

abstract node associated with that management node. Each 20 manager 1206. 

management node also advertises these tunnels to each of its The receiving admission manager now forms a 200 OK 

next-neighbour management nodes, where a "next- response to the chosen INVITE message. The 200 OK 

neighbour" management node is one which is directly response needs to be returned along the same path as the 

connected to the management node via a tunnel. Each such chosen INVITE message arrived. The path along which the 

advertisement contains information about the source, desti- 25 chosen INVITE message arrived is known from the details 

nation and capacity of the tunnel concerned, of each abstract node passed on route. This information is 

Each of the associated abstract nodes, (i.e. those at which taken from the Record-Route header of the chosen INVITE 

a tunnel originates or terminates) advertises one or more message and used to form a new path description for the 200 

labels that may be used by future communication sessions to OK message. Also, the Record-Route header of the chosen 

traverse the tunnel concerned. These advertisements are 30 INVITE message is copied into the 200 OK message. The 

made directly to their controlling admission manager to 200 OK message is then sent back to the originating admis- 

connection manager only, in the management layer. This sion manager. 

differs from the method described in U.S. Ser. No. 09/345, However, before the 200 OK response is sent back, the 

069 in which labels were not advertised from the physical admission manager 1204 (FIG, 11) consumes a label for the 

layer to the management layer. 35 communication session. That is the admission 1204 manager 

When an abstract node advertises a label, information selects one of the advertised labels that are stored or cached 

about that label reaches and is stored or cached at the at that admission manager. The admission manager then 

management node that is associated with the "downstream" informs its associated endpoint 1201 that it has chosen a 

end of the tunnel. The term, "downstream" is used to refer particular label, in order that the endpoint 1201 does not 

to a direction along a communication link which is towards 40 advertise that label as being available any more. The admis- 

the required destination of that communication link. The sion manager also informs its associated endpoint 1201 

term, "upstream" is used to refer to the opposite direction. about the identity of the required communication session. 

The advertisements are made using the COPS interface The endpoint then knows that the chosen label and the 

between the management and physical layers or any other required communication session are associated, 

suitable interface and message protocol. For example, a 45 The admission manager 1204 now sends the 200 OK 

Label Distribution Protocol (LDP) and interface may be response together with the chosen label, to the first connec- 

uscd. tion manager 1206 in the record-route list. That connection 

At this stage in the method, the preferred path has not yet manager 1206 then converts its temporary reservation for 
been chosen using the SIP++ method and yet labels for use the requested communication session into a permanent res- 
in a communication session are already being advertised. In 50 ervatioo. Next, the connection manager 1206 examines the 
this way the two processes of path selection and session record route list to identify which connection manager to 
establishment become integrated. forward the 200 OK response to. Supposing that this next 

FIG. 11 illustrates the advertisement of labels by abstract connection manager is 1207 in FIG. 2, the first connection 

nodes or label switch routers (LSRs). FIG. 11 illustrates a manager 1206 determines a tunnel to connection manager 

communications network with a physical layer comprising 55 1207 and consumes a label for that tunnel. That is, one of the 

abstract nodes 1200 and endpoints 1201, 1202 in an MPLS labels cached at the first connection manager 1206, which is 

communications network. The communications network has suitable for the chosen tunnel, is selected, 

been pre -configured as described above and tunnels are Information about this chosen label is sent from the first 

provided in the direction indicated by arrow A. A commu- connection manager 1206 to its associated abstract node in 

nication session is required to be established between end- 60 order that that abstract node does not rc-advertise the 

point 1202 and endpoint 1201 in the direction of arrow A. particular label. Also, information about the previously 

This direction is termed "downstream". chosen label (that suitable for the journey between the first 

As described above the first stage of the SIP++ negotia- connection manager 1206 and the destination endpoint 

fion process takes place as in U.S. Ser. No, 09/345,069, now 1201) is sent from the first connection manager 1206 to its 

pending. That is, INVITE messages are sent from an admis- 65 associated abstract node. This enables the associated 

sion manager 1203 associated with the first endpoint 1202, abstract node to set up a label mapping. In future, if the 

to the admission manager 1204 associated with the second associated abstract node receives a packet with a label 
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corresponding to the most recently chosen label, it "knows" 
to forward the packet to the destination endpoint using the 
previously chosen label. 

The first connection manager 1206 then sends the 200 OK 
response to the next connection manager together with the 
most recently chosen label and the process repeats until the 
200 OK response reaches the originating admission manager 
1203. This process is illustrated in FIG. 12 which shows a 
200 OK response 1300 carrying a label between the desti- 
nation admission manager and the first connection manager 
1206, and also between subsequent connection managers 
1301, 1302 in a path to the originating admission manager 
1203. Communication between the physical and manage- 
ment layers is also illustrated. Decisions about which label 
to select are sent from the management layer to the physical 
layer and information about corresponding pairs of labels is 
communicated 1304 between next-neighbour abstract nodes 
in the physical layer. 

When the 200 OK response reaches the originating admis- 
sion manager 1203, the originating admission manager 1203 
informs the originating endpoint 1202 which label it should 
use to reach the first abstract node (or LSR) in the selected 
path. This information is matched up with a session descrip- 
tion that the originating endpoint holds for the forward 
mapping of the required commuaication session. At this 
point the path between the endpoints 1202, 1201 is com- 
pletely specified and established for the required communi- 
cation session. This is achieved without the need for a 
separate CR-LDP negotiation to take place, after the SIP++ 
negotiation is complete. Hence, one complete round trip of 
control messages is efiminated and this significantly reduces 
session setup time. 

FIG. 13 illustrates the details of the COPS messaging 
process for the situation where the registration of tunnels is 
akeady complete and advertised labels have been cached. In 
FIG. 13 the management nodes and physical nodes are 
represented by vertical lines with pairs of management 
nodes and associated physical nodes next to one another. 
The downstream direction is indicated by arrow B. 

One cached label 1400, 1401, 1402 is shown for each 
management node 1404, 1404, 1405 but this is for illustra- 
tive purposes only. A plurality of labels may be cached at 
each management node. 

An INVITE message 1406 is illustrated as being received 
at the destination admission manager 1403. The destination 
admission manager then consumes a label, which in this case 
is the only label 1400 cached at that admission manager. The 
destination admission manager informs its associated end- 
point 1407 of the consumed label 1400 in a decision 
message 1410. The decision message 1410 contains infor- 
mation about the consumed label, in this case, label t3-s3 
and also label to session mapping information, in this case, 
label t3_s3-*sdp. As well as this the decision message 1410 
contains client handle information, in this case, clienthandle 
c3, which enables the endpoint to cross-check the indicated 
label. 

The destination admission manager 1403 now sends a 200 
OK response 1411 and adds to this the chosen label, in this 
case, label t3_s3. When the first connection manager 1404 
receives the 200 OK response 1411, it determines the next 
connection manager 1405 in the path and consumes an 
appropriate label, in this case label 1401. The first connec- 
tion manager 1404 then indicates this consumed label 1401 
to its associated label switch router 1408 together with 
information about the previously consumed label 1400. The 
label switch router 1408 then "knows" to make a mapping 
between label 1401 and label 1400. 
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FIG. 13 does not illustrate COPS report state messages. 
These can be used as checks to ensure the correct label 
mapping was established. For example, when a decision is 
received by a physical node from a management node, a 

5 report message may be sent back from the physical node to 
the management node detailing the established label map- 
ping. A check can then be done that the correct label 
mapping was made. Also, in the event that an incorrect label 
mapping is supplied from the management layer to the 

10 physical layer, then a report state message can be used to 
alert the management layer to this error This error message 
may trigger a SIP error message which enables the path to 
be re-negotiated. 
Alternatively, report state messages can indicate that a 

15 different label was used (other than the one indicated in the 
decision message) in order that the subsequent 200 OK 
message may incorporate the label that was actually used. In 
this case, the actually used label is marked in the 200 OK 
message in such a way that that each management node 

20 re-does its label mapping negotiation and frees the previ- 
ously consumed label. 

As^ mentioned above, an LDP messaging process may be 
used instead of the COPS messaging process. An LDP 
messaging process is illustrated in FTG. 14. As for FIG. 13, 

25 management nodes and physical nodes are represented by 
vertical lines. 

LSRs 1501, 1502 and endpoints 1503 advertise their 
available labels using Label Mapping Messages 1504, 1505, 
1506. Each Label Mapping Message (LMM) includes an 

30 address which is the destination of the tunnel for which the 
label is advertised. This address is called a Forwarding 
Equivalence Class (FEC). 

Once a label is consumed by a management node, infor- 
mation about the selected label is communicated to the 

35 associated physical node using further "response" LMMs. 
For example, admission manager 1507 consimies LMM 
1504 and communicates this information to its associated 
endpoint 1503 via a "response^' LMM 1508. The response 
LMM 1508 contains a message identifier, in this case, Msgld 

40 c3, which is the same as the message identifier for the 
consumed label 1504. The endpoint 1503 is then able to 
create a mapping between the label it advertised 1504 using 
this message identifier and the label it has received from the 
admission manager 1507. 

45 Each response LMM also contains the FEC of the session 
so that the label is uniquely linked to the particular session. 
The FEC can be extended to include a port number. This 
prevents confusion in the event that multiple sessions to the 
same user are required, because non-extended FECs only 

50 contain an Internet Protocol address. 

Once the admission manager 1507 has consumed a label 
1504, it includes this label in a 200 OK response 1509 and 
forwards the 200 OK response to the next connection 
manager 1505 in the record route header. The process then 

55 repeats until the 200 OK response reaches the originating 
admission manager (not shown in FIG. 14). 

Shortly after the originating endpoint and admission man- 
ager have received the 200 OK response, all the remaining 
temporary reservations (that have not been converted to 

60 permanent reservations) time-out. 

Using this method, each endpoint need only be aware of 
the congestion locally yet it is possible to choose a path with 
the most favourable end-to-end congestion. Each admission 
manager and its associated endpoint are referred to as a 

65 "decision point". If the network is expanded to include many 
abstract nodes then it is possible to use intermediate decision 
points between the decision points associated with each 
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endpoint. This helps to ensure that congestion information 
does not become too stale, and addresses the problem of 
congestion at locations distant from an endpoint being 
difficult to determine i.e. when there is no visibihty of 
congestion from a given endpoint. 

Having received the 200 OK response, the originating 
endpoint and its associated admission manager complete the 
setup with an ACK message. The ACK message needs to be 
sent back to the destination endpoint along the chosen route. 
The Route header for the ACK message is determined from 
the Record-Route header of the 200 OK message. The 
originating admission manager then sends the ACK message 
along the exact path chosen. It is not essential to use an ACK 
message; however, ACK messages are a required part of the 
SIP protocol and are therefore used in the present example, 
to reduce the modifications required to the SIP protocol in 
order to form the SIP++ protocol. 
Path Selection Alternative 

In a preferred embodiment, as described above, a soft 
state mechanism is used at each of the connection managers 
in the path that a successful INVITE message traverses. A 
short-lived reservation that holds the session bandwidth in 
each label switch path is made such that the bandwidth 
cannot be offered to other proposed communication ses- 
sions. This soft-state is confirmed by the final path decision 
message (e.g. 200 OK message) that turns this temporary 
reservation into a hard state. In the meantime the other 
reservations time out 

In this preferred embodiment there are two possible points 
at which the reservation can be made. If the INVITE 
message includes the rank for each suggested path then the 
receiving endpoint can make a decision as soon as it has 
received all the INVITE messages for a session. The 200 OK 
reply can then be routed over the selected path and used to 
reserve the bandwidth at each of the connection managers 
traversed. The final ACK in this case can be used to return 
any session identifying labels to the called endpoint. 

In the other scheme, the originating admission manager 
sends no rank information in its INVITE messages. It waits 
for 200 OK responses from the called admission manager 
and assigns a rank to each of the returned path aUematives. 
It then makes a decision based on the ranks it has assigned 
and those it has received from the called admission manager. 
An ACK message is then used to traverse the chosen path 
and reserve the bandwidth at each of the connection man- 
agers it passes. 

Alternative Reservation Options 

Two other schemes for reservation of bandwidth at the 
connection managers along the chosen path across the 
MPLS network are now described. 

In a first scheme the standard CR-LDP protocol is modi- 
fied to include a new CR-LDP Type-Length- Value element 
(TLV) that defines the Call-ID of the SIP++ session that 
reserved the bandwidth. Alternatively a vendor specific TLV 
type within the standard CR-LDP is used. In this case, when 
the CR-LDP method is used to establish a path for the 
session (after the path has been reserved using the SIP++ 
protocol) the Call-ID is used to make sure that the CR-LDP 
method sets up the same path as that selected by SIP++, 
During the CR-LDP method to establish a path for the 
session, each label switch router in the path uses COPS to 
interrogate its associated connection manager with the Call- 
ID. This is done using COPS request messages. On request 
the connection manager returns the label switch path (of the 
reserved path chosen by SIP++) down which the session 
should be directed, using a COPS Decision message. 

Alternatively, the connection manager uses a Synchronise 
State Request to signal a change in client (in this case label 
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switch path) state with the update arriving in the form of the 
CR-LDP message itself. When this 'update^ is received the 
label switch router responds with a Synchronise State Com- 
plete message. Using this method, each connection manager 
S advertises the reserved path to its associated label switch 
router to ensure that the reserved path is used 

As an alternative to making a soft-state reservation per- 
manent using an SIP++ message. Request messages sent by 
label switch routers to their associated connection managers 
can be used to make the reservation in the connection 
manager. 

In the alternative method, on receipt of the Request 
containing the Call-ID of the session, the connection man- 
ager matches the Call-ID to the Call-ID of a previously 
received INVITE message and makes the reservation for the 

1^ session. 

More Details About SIP++ 

The INVITE method of SIP is re-used in SIP++ with a 
new body type, a changed use of the SIP INVITE method 
and a slightly changed header type. 

20 The header type is the Record-Route header. It operates in 
essentially the same manner as in standard SIP but the 
manner in which it is filled in is different. The Record-Route 
header is used to log a set of nodes that all subsequent SIP 
responses must be routed through. Typically this is used by 

25 proxies to monitor session set-up. 

Under SIP++ operation, when a connection manager 
receives an INVITE message, it appends a SIP-URL 
(Universal Resource Locator) of its identity to the Record- 
Route header. This identity consists of the name of the 

30 connection manager and the IP address of the label switch 
router it is administering e.g. sip: CM Harlow@1.2.3.4. 
Where CM_Jlarlow is the name of the cormection manager 
and 1.2.3.4 is the IPv4 address of the label switch router. 
Each subsequent connection manager appends its SIP- URL 

35 to the front of the list of SIP-URLs. This process is illus- 
trated in FIG. 4 which shows two connection managers 43, 
44 together with their associated label switch routers 45, 46 
which are each part of an abstract node 41, 42. One 
connection manager is called "CM London" and the other 

40 "CM Paris" as illustrated. For CM London, the IP address is 
47.123.4.98 and for CM Paris, 47.59.34.2. The record-route 
header of an INVITE message received by first CM London 
and then CM Paris are shown 47, 48 and it can be seen that 
for CM Paris the SIP-URL for this connection manager has 

45 been appended to the front of the list of SIP-URLs. When a 
Route header is present in a SIP message it defines a set of 
nodes that the message must be routed through. A connec- 
tion manager can thus be regarded as acting like a SIP Proxy. 
The SIP++ message body introduces six new elements as 

50 compared to a standard SIP message body and these are now 
described. 

Abstract Node Element. 

This element is used to specify a particular abstract node. 
Parts of the specification for the abstract node can be 

55 "wildcarded" (for example, if it is required to find all 
possible routes which pass through an abstract node which 
meets certain specifications). The abstract node element uses 
the following notation: {prefix length, IP address}, where 
the prefix length acts like a subnet mask for the IP address 

60 field and specifies the number of bits, starting with the MSB 
(Most Significant Bit), of the IP address which are used to 
describe the Abstract Node. If a prefix length of 32 is used, 
the whole IP address is significant and this is termed an 
exphcit address. For example, {24, 47.209.3.1} defines an 

65 Abstract Node whose elements^ IP addresses begin with 
47.209.3 and {32, 47.209.3.1} defines an Abstract Node 
with the explicit address 47.209.3.1. 
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Another example is {0, 47.209.3.1} which defines an 
Abstract Node with no completely defined IP address. Use 
of the zero at the front of the element is equivalent to a 
wildcard value and useful when the originating cndpoint has 
an incomplete view of a part of the network, or wishes to 
find out how many paths exist over a particular leg. A short 
form of the wildcard value, for example: {*,*} may also be 
used. 

Path Elemeat. 

This is a string of Abstract Node definitions — in 200 OK 
and ACK messages it is a string of explicit addresses. It 
contains as many abstract node definitions as there are hops 
across the MPLS network to the destination endpoint. (A 
"hop" is a path between two abstract nodes) A path element 
has the following format: Path-{{AN1}, {AN2}, {AN3}, . 
. . , {EP}} where the last element in the path is the explicit 
address of the destination endpoint (otherwise routing is 
impossible). 

A path element may contain wildcard characters. 
However, to avoid unnecessarily large amounts of 20 
signalling, there arc preferably no more than two successive 
wildcard addresses in a path definition. There may only ever 
be one path element per message body. 
Rank Element 

This is a score from 0-10 that indicates the preference an 
endpoint has for a particular path, with 10 being the favou- 
rite route. If a score of 0 is received for a particular path, this 
indicates that it is totally unacceptable and should not be 
used. An example of a rank element is: Rank»6. 
Traffic Element 

This element uses the exact set of parameters that the 
Traffic TLV in CR-LDP uses, namely: Peak Data Rate 
(PDR); Peak Burst Size (PBS); Committed Data Rate 
(CDR); Committed Burst Size (CBS); Excess Burst Size 
(EBS). All the rates are quoted in KBPS- An example of a 
traffic element is; Traffic={PDR=128, PBSo512, CDR=96, 
CBS-256, EBS-512}. 
Label Element 

This is used to convey any locally assigned path or "label" 
information from one endpoint to another; typically from the 
originating endpoint to the called endpoint. The session at 
the originating endpoint is mapped into a particular label 
switch path over its first hop with many other sessions. In 
order to allow differentiation at the called endpoint (and thus 
faster onward routing) a second label is inserted at the 
bottom of a label stack which remains unpopped until 
received by the called endpoint. Label elements are used by 
ACK messages only. Also, depending on the coupling 
between the endpoint and admission manager, label ele- 
ments are only sent once CR-LDP negotiation is complete. 
An example of a label element is: Label=928. 
Resource Class Element 

This element is used to indicate the resource class of the 
session for the purposes of DiflfServ support. An example of 
a resource class element is Class=42. It is not essential to use 
resource class elements if DifiCServ support is not required. 

Resource class elements may also be used to group 
sessions in a particular label switch path. Where multiple 
label switch paths exist between two abstract nodes, the 
selection of which of these to use for a new session can be 
made if each of these label switch paths carries a distinct set 
of Resource Classes. For example, a pre-configured path 
may be arranged to only carry a session whose resource class 
lies in the range 20-500. This also allows label switch paths 
to be tailored to suit particular session types. 

The SIP++ protocol makes use of 4 of the main SIP 
methods in a new form, namely: INVITE; ACK; REGIS- 
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TER and BYE. The operation of these methods in the SIP++ 
protocol is now described. 
INVITE Method 

One way in which the SIP++ INVITE method differs from 
the standard SIP INVITE method involves so called "fork- 
ing". When the next abstract node in a path element results 
in a number of possible paths for the next hop, the INVITE 
message is duplicated and sent along each possible path. 
This is termed "forking*'. In SIP++ forking is only arranged 
to occur if the next-but-one abstract node is reachable 
through the next abstract node. However, in standard SIP 
forking does not rely on topological information; forked 
INVITE messages are simply seat down all possible paths 
when forked. 

Forking in SIP++ is illustrated in FIG. 5. Four abstract 
nodes 51, 52, 53, 54 are illustrated each having an associated 
connection manager 55, 56, 57, 58. Connection manager X 
55 receives an INVITE message with the next hop wild- 
carded. It has 3 label switch paths 60, 61, 62 down which it 
might fork the INVITE message. The connection manager X 
55 therefore examines the next abstract node definition, in 
this case an endpoint 63 address. Having done this, CM X 
55 realises that paths only exist to the destination endpoint 
63 via the abstract nodes 52, 54 administered by connection 
manager Y 56 and connection manager Z 58. The INVITE 
message is thus only forked to these Connection Managers 
56, 58 and not to connection manager A 57. This example 
illustrates the need for each Connection Manager to main- 
tain topological information over two hops. 

SIP++ permits multiple INVITE messages to be issued 
with the same Call-ID (but with an incremented identifier 
called a "Cseq"), without first receiving a 200 OK response 
for the first INVITE. However, under standard SIP 
operation, each INVITE message is issued sequentially and 
must be responded to either with an enror or a 200 OK. 

On receipt of a 200 OK message by an admission manager 
or connection manager, the session described by the asso- 
ciated INVITE message is considered established and no 
further INVITE messages need to be sent. S1P++ allows a 
destination endpoint to choose a path from a number of 
INVITE messages and to respond with a single 200 OK 
message. To avoid confusion, each INVITE message whose 
path was not used is sent an error response indicating the 
path was not used. This error response contains the CSeq 
identifier of the unsuccessful INVITE message. It is a 
preferred embodiment that these Error messages be sent, 
though their omission has no detrimental effect to the 
operation of the protocol. 

A 200 OK response issued by an admission manager 
includes the CSeq of the INVITE associated with the chosen 
path. As illustrated in FIG. 6 the body of the 200 OK 
message includes a path element 601 for the selected path. 
This is formed from the label switch path IP addresses 602, 
603, 604 listed in the Record-Route header 605 of the 
INVITE message 606, These IP addresses are listed in the 
path element as explicit Abstract Nodes. They are retrieved 
in the order in which they were appended to the INVITE 
message, so that the left-most SIP-URI in the header gives 
the right-most abstract node in the path element. A destina- 
tion endpoint 608 then adds its own IP address 607 to the 
path element. 

The originating admission manager is able to correlate its 
successful requested path element that it sent with the actual 
path reserved, and store this for future use. 

The number of INVITE messages which may be issued 
for a particular session depends on both the number of 
diverse routes an endpoint wishes to explore, and whether 
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the originating endpoint receives a satisfactory response to 
an INVITE message. It is preferred that the number does not 
exceed about 5 INVITE messages. 

Diverse routing can easily be achieved by issuing a 
number of concurrent INVITE messages for the same ses- 
sion. These use the same Call-ID but different CSeq value. 
The receiving endpoint then chooses whether to reply to all 
the INVITE messages with a single 200 OK message, or to 
reply with one 200 OK message per INVITE message 
received. 

There therefore exists at least two mechanisms within 
81?++- for diverse routing, firstly by using wildcard or short 
prefix abstract nodes, and secondly by sending multiple 
INVITE messages for the same session. 
ACK Method 

The ACK is used in the same way as in standard SIP. It 
is used to terminate an INVITE message as described above. 
REGISTER Method 

The REGISTER method is used to update the topology 
and congestion information in the network, and also to 
inform Connection Managers and Admission managers of 
the existence of a label switch path. When a label switch 
router receives a path set-up message from the administra- 
tive server, it sends a Request message over the COPS 
interface to its coonection manager. This triggers the con- 
nection manager to broadcast a REGISTER message to all 
neighbouring connection managers that details the new path 
in terms of its size and the abstract nodes between which it 
exists. This initial advertising may either be to all neigh- 
bouring connection managers or just to those whose abstract 
nodes have a preferred label switch path to the newly 
configured abstract node. The REGISTER is then forwarded 
one hop further such that all connection managers and 
admission managers now have information about the topol- 
ogy of the network up to two hops away. 

REGISTER messages arc also used as periodical updates 
of the state of each label switch path. In this case, the 
information sent is the remaining free space in the label 
switch path and the abstract nodes between which the label 
switch path runs. These REGISTER messages are only sent 
to those connection managers whose abstract nodes have a 
direct connection to the sending connection manager* s 
abstract node. The REGISTER messages are then forwarded 
over the next hop in the same manner. The distance over/ 
which they are sent can be limited using the Max-Forwards 
SIP header. The time period for these updates is arranged to 
be short enough that the topology and congestion informa- 
tion in the network does not become stale, but long enough 
that the network does not become flooded. 

Congestion information may, additionally, be piggy- 
backed on INVITE and 200 OK messages. This involves 
attaching the congestion body type onto the end of the 
normal INVITE message. If such a mechanism is used, it 
restarts the REGISTER update timer every time an INVITE 
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ERROR Messages 

New error messages are needed for the SIP++ protocol. 
Five are needed and these have subtly different meanings: 

1) 801 Congestion: LSP unable to take new session 

2) 802 Congestion: LSP has reached its capacity — may be 
issued following a successful set-up 

3) 803 Not available: LSP has temporary fault (other than 
it is congested) 

4) 804 Not available: No such LSP exists. 

5) 810 Path not used (in response to an unsuccessful 
INVITE) 

BYE Method 

BYE clears the reservation in each of the connection 
managers in the session path. The use of the previously 
established Route header ensures each connection manager 
is traversed and the Call-ID uniquely identifies the session. 
A BYE message is only sent once the session has cleared at 
the MPLS layer. A BYE message can be sent by an admis- 
sion manager associated with either endpoint. 
The COPS Protocol 

In a preferred embodiment of the present invention, the 
standard COPS protocol is used for communication between 
various elements in a communications network as described 
above. However, other messaging protocols which perform 
the same function may also be used. The way in which the 
standard COPS protocol is used in an embodiment of the 
present invention is now described. 

fjlhis' protocol defines.a-client-server messaging mecha- 
nism that supports^ po lisy^^^fo rgement^ in a Qualify of 



Service enabled netw6rk.~The 'basic-functional blocks used 
by the COPS protocol are shown in FIG. 7 and its basic 
operation can be described as follows. A new Quality of 
Service session request is received by a Policy Enforcement 
35 jljoint (PEP) — this request can be an RSVP path message or 
in a preferred embodiment of the present invention a 
CR-LDP message, although COPS is intended to be protocol 
independent. The PEP now queries a Policy Decision Point 
(PDP) as to whether it should allow this new session to be 
40 / set-up. The PDP issues a response and the PEP implements 
; , this — either to deny the new session or to allow it to be 
/ set-up. A local policy decision point (LPDP) 703 is also 
included in the model as a method of getting a quick 
< response to a query. The LPDP is only allowed to issue 
temporary decisions, pending a response from the PDP In a 
preferred embodiment of the present invention an admission 
manager performs the functions of a PDP and an endpoint 
that of a PEP. 

The COPS protocol uses a simple set of messages as 
0 illustrated in FIG. 8. Client Open 801, Client Accept 802, 
\ Client Close 803 and Keep Alive 804 are used to administer 
; \the connection from the PEP (Client) 701 to the PDP 
(Server) 702. New session requests are handled by a 
^ Request-Decision-Report State handshake 805. There is also 
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message is used in this way. The period for this mechanism 55 a capability to synchronise the PDP and PEP with respect to 



may be on an every n packets basis, where n is small, for 
example 20. In this way, at times of heavy session set-up, 
and thus high flux in the network congestion state, more 
regular congestion information is exchanged. This mecha- 
nism is not used to notify a new label switch path — this is 
always achieved using the REGISTER method. 

A REGISTER message is not forwarded along the label 
switch path that the message describes. Similarly, the con- 
gestion information attached to INVITE and 200 OK mes- 
sages does not describe the tunnel being traversed. In this 
way, congestion can always be fed upstream to provide 
negative feedback, control and network stability. 
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the active^sessions on the PEP. 
v Although COPS is a policy messaging protocol, it places 
jUO restriction on the type of policy information that it can 
/exchange. In its role in the network described in this 
document, COPS is typically required to convey the infor- 
mation needed to establish a CR-LDP session over the 
interface between an endpoint and admission manager and 
between an admission manager and administrative server. In 
the former case, the endpoint issues a Request for a new 
session, with the Decision indicating failure or success and 
the-parameters decided upon by SIP++ to use to set-up the 
session. In the Latter case, an admission manager requests a 
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new tunnel in the MPLS core to be set-up by the Adminis- 
trative Server. For example, this may be prompted by a 
Request from an cndpoint. 

In a preferred embodiment of the present invention, when 
COPS is used between a connection manager and an abstract 
node COPS messages carry a Call-ID as well as CR-LDP 
information. In this embodiment the protocol is used as a 
registration process, with all requests being granted under 
normal operation. 
The CR-LDP Protocol 

The CR-LDP protocol is now described for background 
information and in order to better illustrate the context of the 
present invention. However, it is not essential to use the 
CR-LDP protocol in the present invention. 

The standard CR-LDP (Constraint-based Routing Label 
Distribution Protocol) protocol is an extension of the basic 
LDP protocol used to establish labelled flows in MPLS 
networks. It is designed to allow traffic engineering methods 
to be applied to an MPLS network such that specific paths 
can be established through a set of chosen nodes with a 
particular Quality of Service. CR-LDP is a messaging based 
protocol that uses TLV (Type Length Value) elements to 
encode data. 

The standard LDP protocol is used to establish label 
mappings at a label switch router (LSR) between incoming 
and outgoing label switch paths (LSPs). A particular LSR is 
able to request from a peer a label that can be used to specify 
the route to that LSR. MPLS is thus able to transport IP 
packets across a network in a hop-by-hop manner by swap- 
ping labels at each node in the network. 

CR-LDP extends this to cover multiple hops in an MPLS 
network and its basic operation is illustrated in FIG. 9. A 
LSR issues a Label Request Message 901 which specifies 
the path 902 to be taken through the network and optionally 
the traCBc characteristics, resource class, pinning options etc. 
for the path. The Label Request message is then sent to the 
first LSR 903 in the path. This can be an abstract node 
representation, though standard CR-LDP has no defined 
method for choosing which LSR to use if more than one 
reachable LSR is specified by an abstract node representa- 
tion. By constraining the network, as described herein, by 
only allowing sessions to be established along pre- 
determined paths this problem is effectively dealt with. 

When the next LSR is reached, it identifies itself as being 
the next LSR in the path and removes itself from the path 
description 904. It then checks that there is another hop 
specified for the path and the modified message 905 is 
forwarded. This processing occurs until the final LSR 906 in 
the specified path is reached. At this point a Label Mapping 
Message 907 is returned back across the network through 
each of the nodes traversed. Each upstream LSR in turn 
indicates a label to the downstream LSR to use over that hop 
of the MPLS network. The Downstream LSR adds this value 
into its routing table 908 and issues a similar message. This 
process continues back to the originating LSR 909, at which 
point the LSP is completely set-up and ready for use. 

Once established, the path behaves as though it is a single 
hop between two LSRs 909, 906, regardless of how many 
LSRs are actually traversed. It may also be used in subse- 
quent CR-LDP paths as one of the hops. 

Network Initialisation 

The process of network initialisation is similar to the 
method used to establish a new link between Abstract 
Nodes. As noted above, although a link may exist between 
two groups of label switch routers (LSRs) which are 
grouped together to form an Abstract Node, the label switch 
path (LSP) established will be between two LSRs, one from 
each of the Abstract Nodes connected together. 
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The Administrative Server initialises the network Unk by 
link, sequentially establishing the high capacity LSPs to use 
over the network core. As soon as the link is active, its 
associated connection manager begins to advertise its pres- 
ence to all other reachable nodes. As more links are 
established, the set of reachable nodes from each connection 
manager is increased until aU links are present. 

In FIG. 1 it can be seen that the cndpoints 10, 11 do not 
have any high capacity links to their nearest abstract nodes 
12, 14. Rather these connections are set-up on demand. The 
Administrative Server 35 therefore also initiates the for- 
warding of congesUon information to an Endpoint 10, 11 
from those Abstract Nodes which the endpoint 10, 11 is 
allowed to access as the first hop on a given path. The set of 
15 abstract nodes an endpoint can reach may be decided on a 
topological or bandwidth basis and are decided by the 
network provider. The Admission Manager 35 is then able to 
build up a picture of the paths available to it. 

Should an Admission Manager 30, 31 need greater access 
20 ,to the MPLS network, it uses the COPS interface to the 
Administrative Server 35 to request access to another 
Abstract Node. 

End to End Session Establishment 

An example of the messaging used to establish a com- 
munication session across a communications network and 
provide a guaranteed quality of service is now described 
with reference to FIG. 10. 

The first event is the arrival at an endpoint 1100 of a new 
session request 1101. There is no restriction on the type of 
request this can be, though it must obviously be one the 
endpoint 1100 understands. This causes the endpoint 1100 to 
send a COPS Request (labelled Al) to its associated Admis- 
sion Manager 1102. Upon receipt of this Request, the 
Admission Manager 1102 determines the path or paths it 
will attempt to use to route the session to its destination. This 
may be either an explicit path or may use abstract nodes, 
depending on the amount of network topology information 
available to the Admission Manager 1102, Using its view of 
the network congestion and any associated route selection 
policies, the admission manager 1102 assigns a rank to each 
of the paths it has determined. 

The Admission Manager 1102 then forms one INVITE 
message for each of the paths using the same Call-ID for 
each, but different Cseq values. Each INVITE message 
includes a path element, an associated rank and a traflSc 
element in the message body. It will also include a session 
description message body. Each INVITE message is then 
sent A3 to each of the connection managers 1103, 1104, 1105 
in turn that control Abstract Nodes 1106, 1107, 1108 in the 
specified path before finally reaching the destination admis- 
sion manager 1109. 

At each Connection Manager 1103, 1104, 1105 in the 
path, the path element of the INVITE message is interro- 
gated for the next Abstract Node. The Connection Manager 
then determines if it has a label switch path (LSP) to that 
Abstract Node with sufficient free resource by comparison 
with the traflSc element. If it has, it writes its SIP-URL into 
the Record-Route header of the INVITE message. The 
Connection Manager now adds a temporary soft-state res- 
ervation associated with the call-ID along the path and 
awaits confirmation. The Connection Manager may also 
choose to add a congestion message body to the message. 
The INVITE message is now forwarded to all Connection 
Managers whose Abstract Nodes were identified as suitable 
next hops using forking as described above. The final 
Connection Manager in the MPLS network implicitly per- 
forms an unforking operation by routing all INVITE mes- 
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sages to a single Admission Manager 1109. If the final 
Abstract Node 1108 is not described by an explicit address, 
an error response is generated. 

If any of the traversed connection managers 1103, 1104, 
1105 in the path have a next hop LSP which is currently too 
congested that connection manager responds with an 801/ 
802 error response and ceases forwarding the INVITE 
message. The Record-Route header is used to route the 
response back. Any connection managers this error response 
traverses then update their congestion information accord- 
ingly. If the next hop LSP is not congested but unavailable 
for some other reason, an 803 response is sent and if the next 
abstract node in the path is simply unreachable from this 
connection manager, an 804 response is sent. 

The destination Admission Manager 1109 eventually 
receives one or more INVITE messages. Upon receipt of the 
first INVITE message for a new session (i.e. an INVITE 
message that has an unrecognised Call-ID) a timer starts and 
all INVITE messages with the same Call-ID received within 
the time limit are processed. The Admission Manager 1109 
then begins to form a 200 OK response. It uses the Record- 
Route headers of each incoming INVITE message to deter- 
mine the path taken by that message. It ranks each of these 
paths and by convolution with the original ranking scores, it 
chooses a preferred path. Any suitable path weighting and 
cost algorithms may be used to help form the rank. 

The destination admission manager 1109 now sends one 
810 response per original INVITE message whose path was 
not used (i.e. one per CSeq value). It also then sends a 200 
OK response for the chosen path, using the Record-Route 
header of the original to form the path element in the 
message body. The Record-Route is then also used to make 
a Route header. Finally, the Admission Manager 1109 stores 
the session description and Call ID before returning the 200 
OK message A6. As this message traverses the connection 
managers 1105, 1104, 1103 listed in the Route header, it 
triggers the making of permanent reservations for the ses- 
sion at each traversed connection manager by up-dating the 
existing soft-state reservation. 

As the 200 OK message traverses the connection 
managers, labels are consumed as described above in order 
to establish label mappings for the selected path. 

On receipt of the 200 OK message, the originating Admis- 
sion Manager 1102 closes the SIP++ negotiation process by 
sending an ACK message A7 back across the network using 
the chosen path as its route — gleaned from the received 
Route header. The receiving Admission Manager 1102 uses 
this ACK message to update its congestion information with 
the new session and as a confirmation of the path chosen. 
The originating Admission Manager 1102 also updates its 
path description for the session to reflect the chosen path. 

Because the communication session has now been set up 
it is not necessary for the Endpoint UOO to start a CR-LDP 
negotiation A9 using the path of explicit nodes 1106, 1107, 
1108 and including the Call-ID as a vendor specific TLY It 
is not necessary to use CR-LDP to establish a path through 
the specified LSRs and this reduces setup time significantly. 
Bi-directional Communication Sessions 

In one embodiment the communications network is an 
internet protocol communications network and is used to 
perform telephony operations. In this case a communica- 
tions network similar to that shown in FIG. 15 is used, which 
incorporates call servers (CSs) 2000. The communications 
network of FIG. 15 is the same as the communications 
network of FIG. 1 with corresponding components labelled 
with the same reference numerals. FIG. 15 does not show an 
administrative server although this may be incorporated into 
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the communications network as shown in FIG. 1. Terminals 

2001, 2002 are also shown in FIG, IS, one terminal con- 
nected to each endpoint. Many terminals may be connected 
to each endpoint although this is not iUustrated. The tenni- 

5 nals 2001, 2002 are illustrated as telephone handsets, 
although any terminal suitable for accessing an internet 
protocol communications network may be used. 

The call servers 2000 arc connected together via an ISUP 
standard interface (which is part of the ITU signalling 

10 system no. 7 protocol) or any other suitable interface. Each 
endpoint 10, 11 is connected to a call server 2000, for 
example using the standard media gateway control protocol 
(MEGACO protocol) or any other suitable protocol. 
The call servers handle call-semp signalling between user 

15 terminals 2001, 2002 as well as optional services such as call 
forwarding and are used to provision the path for the session. 
From the point of view of a call server, the only network 
elements are users and endpoints, connected by direct links. 
Several different methods of establi^ing bi-directional 

20 communication sessions over the communications network 
of FIG. 15 are now described. 
Use of ACK Message to Make Reservation 

In a first method it is assumed that the bandwidth require- 
ments for the forward and backward sessions are identical; 

25 that is, that the sessions are symmetrical. In the case of 
telephony over internet protocol communications networks 
this assumption is reasonable because for telephone conver- 
sations both parties typically require similar amounts of 
bandwidth, 

30 Referring to FIG. 16, this shows the communications 
network of FIG, 15 and illustrates a process of setting up a 
bi-directional communication session between telephony 
terminals 2001, 2002. A calling party uses terminal 2001 to 
begin a call by sending set-up information to the call server 

35 2000 that is connected to the endpoint 10 associated with the 
terminal 2001. This call server 2000 is now referred to as the 
originating call server. Any suitable protocol may be used 
for communicating the set-up information from the terminal 
2001 to the call server 2000, for example, the protocol used 

40 may vary depending on the type of terminal 2001 used. 
The originating call server 2000 sends an initial address 
message (I AM) 2003 to the destination call server 2000, that 
is, the call server connected to the destination endpoint 11. 
The lAM would contain information about the address of the 

45 destination terminal 2002, but the originating call server 
2000 replaces this address with the address of the destination 
endpoint 11. The lAM also contains information about the 
calling party's session characteristics, e.g. the type of calling 
party terminal 2001 being used. 

50 When the destination call server 2000 receives the initial 
address message it forwards this to the destination terminal 

2002. The destination terminal "decides" whether it is able 
to receive the call and responds accordingly to the destina- 
tion call server. The response from the destination terminal 

55 2002 contains information about that terminal's session 
needs e.g. the type of destination terminal 2002, 

If the response received by the destination call server is 
positive, that call server issues a create connection (CRCX) 
message 2005 to the destination endpoint 11, This create 

60 connection message 2005 is formed according to the 
MEGACO protocol although any other suitable protocol 
may be used. The CRCX message instructs the destination 
endpoint 11 to fonm a connection between the calling 
terminal's endpoint 2001 and the called terminal 2002. 

65 In order to form this connection part of the method 
described above using the SIP++ protocol is used. First, the 
called endpoint 11 forms a COPS request 2006 and sends 
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this to its associated admission manager 31. One or more 
SIP++ INVITE messages are formed by that admission 
manager 31 in order to select a path for the session, which 
will have the required level of quality of service. As in the 
SIP++ method, described above, an INVITE message 2007 
is propagated across the network to the calling party^s 
admission manager 30 and temporary reservations (for tun- 
nels on the reverse path) are made at each abstract node 
crossed. In addition to this identical temporary reservations 
are also made along the same path but in the opposite 
direction (for the forward path). These reservations are for 
the same bandwidth and quality of service parameters in 
both the forward and reverse directions. This enables band- 
width to be reserved along tunnels towards the caller and 
away from the caller at the same time. 

In the meantime, the destination or called call server 2000 
responds to the lAM by sending a message to the originating 
call server. This message comprises an ANM (Answer 
Message) 2004 which indicates that the called terminal 2002 
is able to participate in the proposed new session. 

When the ANM 2004 reaches the originating call server 
2000, that call server sends a create connection message 
2008 to the originating endpoint 10. This instructs the 
originating endpoint 10 to establish a connection between 
the calling terminal 2001 and the called endpoint U. The 
called endpoint 11 then issues a COPS request 2009 to its 
associated admission manager 30 to initiate the SIP++ 
method. 

In the first part of the method, in which the destination 
endpoint U begins to establish a one-way connection from 
the destination endpoint 11 to the originating endpoint 10, 
INVITE messages are sent from the destination admission 
manager to the originating admission manager. According to 
the SIP++ method described above, when the originating 
admission manager receives INVITE messages, it must 
select a path and issue a 200 OK response. However, in this 
case, the originating admission manager is arranged to wait 
before doing this. That is, the originating admission manager 
does not issue a 200 OK response, until it receives a COPS 
request from the originating endpoint 10 and INVITE mes- 
sages from the destination admission manager. 

When the admission manager has received both the COPS 
request 2009 and the INVITE message 2007 it matches these 
up. That is, the admission manager determines that these two 
messages are related to the same proposed two-way com- 
mimication session. This is necessary, because other two- 
way communication sessions involving different terminals 
may be being set up simultaneously. The matching up 
process is done using information about the sessions con- 
tained in the COPS request 2009 and the INVITE messages 
2007. Alternatively, a circuit identification code (CIC) is 
used. This CIC is included in the create connection messages 
2005, 2008 and is written into the INVITE messages 2007 
by the admission managers 30, 31 or endpoints 10, 11. The 
CIC is then passed to the calling party's admission manager 
30 over the COPS interface using a suitable extension to the 
COPS protocol. The calling party's admission manager 30 is 
then able to match the COPS request 2009 and the INVITE 
message 2007 using the CIC. 

Having correlated the COPS request 2009 with the 
INVITE message 2007, the originating admission manager 
30 sends a 200 OK message 2010 back over the chosen path, 
in the same way as in the SIP++ method described above. As 
the 200 OK message is propagated along this path it causes 
labels to be consumed at each management node along the 
route as described above. In this way, label mappings are 
established at the abstract nodes for the reverse direction of 
the communication session. 
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When the destinadon admission manager 31 receives the 
200 OK message the path from the called party to the calling 
party (i.e. die return path) is considered established. The 
destination admission manager 31 indicates this by sending 

5 a COPS decision message (not shown) to the destination 
endpoint 11. As in the SIP++ method described above, the 
destination admission manager 31 now sends an acknowl- 
edgement message (ACK) 2011 back to the originating 
admission manager. 

10 The ACK message 2011 is sent back to the originating 
admission manager 30 along the same path as the original 
INVITE message 2007. As the ACK passes each connection 
manager 32, 33, 34 along that path, it causes the temporary 
reservations (along the reverse path) to be made permanent. 

15 Also, the ACK causes labels to be consumed at each 
management node along the reverse path and enables label 
mappings for the forward communication session to be 
established. 

When the ACK message 2001 reaches the originating 

20 admission manager 30 the reverse path, &om the called party 
to the calling party, is considered established. The two-way 
communication session is then ready for traffic. The origi- 
nating admission manager 30 sends a COPS decision to the 
originating endpoint 10 to indicate this. When the originat- 

25 ing endpoint 10 receives the COPS decision it informs the 
originating call server 2000 using a MEGACO message. 

In this method, the reverse path is established before the 
forward path is established. This is particularly advanta- 
geous for telephony applications where ringing is applied at 

30 the called party terminal 2002. In such a situation, a back- 
ward path is required for the caller to hear the ringing. 

This method involves establishing a forward path along 
one set of tunnels and a reverse path along corresponding 
tunnels but in the reverse direction. Both the forward and 

35 reverse paths take the same route and have the same band- 
width and quality of service. Using this method, the com- 
munications network is traversed by control messages only 
three times as illustrated in FIG. 16. This enables session 
setup times to be reduced. Also, this method is particularly 

40 suited to situations where the bandwidth required by the 
calling and called parties is similar. 
Re-use of Path Information 

In a second method, the communications network is 
traversed by control messages four times. In this case, the 

45 ACK message is not used to set up the forward communi- 
cation session. Instead a pair of INVITE and 200 OK 
messages are used for each of the forward and reverse paths 
as illustrated in FIG. 17. This means that the bandwidth on 
the forward and reverse paths is not necessarily equal. 

50 The second method follows the first method to the point 
where the originating admission manager 30 receives 
INVITE messages 2007 from the destination admission 
manager 31. The originating admission manager 30 then 
selects one of these INVITE messages 2007 as in the SIP++ 

55 method described above. The path that the selected INVITE 
message took is stored in the originating admission manager 
30. The originating admission manager then proceeds with 
a 200 OK message 2010 as described in the SIP++ method 
above. As this 200 OK message 2010 propagates through the 

60 network, label mappings are established for the reverse path. 
In the meantime, the path stored by the originating 
admission manager 30 is used to form a new INVITE 
message 2012 which is issued by the originating admission 
manager to the destination admission manager 31. By "wild- 

65 carding*' part of the stored path, the new INVITE message 
2012 is arranged to select a route which does not necessarily 
correspond to that of the selected INVITE 2007. However, 
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it is not essential to "wildcard" the stored path in this way, 
in which case, the forward and reverse paths correspond. 

When the new INVITE message 2012 is received by the 
destination admission manager 31, a 200 OK response 2012 
is formed and sent back to the originating admission man- 
ager 30 as described in the SIP++ method above. As the 200 
OK response 2012 propagates from the destination admis- 
sion manager to the originating admission manager, label 
mappings are established for the forward communication 
session, as described above. 

Using this method, a route which is suited to the calling 
party's requirements and which makes best use of the 
available tunnels is chosen. That path is then assumed to be 
optimal for the reverse direction and used in the INVITE 
process for that reverse direction. For example, the band- 
width allocated to the called party and calling party can be 
different. Also, because the forward and reverse routes do 
not necessarily correspond there is no need to match up the 
forward and reverse paths as in the first method. This means 
that CICs are not essential although they may be used. 
Identical Labels 

A third method involves configuring the communications 
network such that the forward and reverse tunnels between 
two LSRs have the same numerical label. In this way, by 
controlling the allocation method of the session labels within 
these tunnels, it is possible to define the forward and reverse 
paths using a single label value which is the same at either 
end of the tunnel. 

Referring to FIG. 18, a tunnel is shown 3000, which 
comprises several session labels 3001 to 3006. The session 
labels are uni-directionaL Between two neighbouring label 
switch routers, two such tunnels 3000 exist and have iden- 
tical session labels in each direction. 

Using this method the forward and reverse paths corre- 
spond and have the same bandwidth. 

Using this method, INVITE messages are sent from the 
originating admission manager to the destination admission 
manager following the SIP++ method described above. The 
destination admission manager selects one of these INVITE 
messages and sends a 200 OK response back along its path. 
As this 200 OK response propagates over the communica- 
tions network, labels are consumed and label mappings 
established for both the forward and the reverse communi- 
cations sessions simultaneously. The process of consuming 
labels and establishing the label mappings may be carried 
out using a COPS messaging process or an LDP messaging 
process in a similar way to the method described above. 

FIG. 19 illustrates use of a COPS messaging process to 
consume labels and establish label mappings for the forward 
and reverse communication sessions simultaneously. FIG. 
19 shows the situation where the tunnels have been regis- 
tered and labels cached as described above. Management 
nodes and physical nodes are represented as vertical lines in 
a similar way as for FIGS. 13 and 14. The forward direction 
is from left to right in FIG. 19. 

One cached label 4000, 4001 is shown for each manage- 
ment node 4002, 4003, but this is for illustrative purposes 
only. A plurality of labels may be cached at each manage- 
ment node. 

An INVITE message 4004 is illustrated as being received 
at the destination admission manager 4002, The destination 
admission manager then consumes a label, which in this case 
is the only label 4001 cached at that admission manager. The 
destination admission manager informs its associated end- 
point 4005 of the consumed label 4001 in a decision 
message 4007. The decision message 4007 contains infor- 
mation about the consumed label, in this case, label t3-s3, 
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and also label to session mapping information for the 
forward direction, in this case, label t3_s3-*sdp. In this 
case, because the communications network has been spe- 
cially configured such that the forward and reverse paths 
5 between two LSRs are defined by a single label, the devision 
message 4007 also contains label to session mapping infor- 
mation for the reverse direction, in this case, label sdp-*t3_ 
s3. 

As well as this the decision message 1410 contains client 

10 handle information, in this case, clienthandle c3, which 
enables the endpoint to cross-check the indicated label. 

The destination admission manager 4002 now sends a 200 
OK response 4008 and adds to this the chosen label, in this 
case, label t3_s3. When the first connection manager 4003 

IS receives the 200 OK response 4008, it determines the next 
connection manager in the path and consumes an appropri- 
ate label, in this case label 4000. The first connection 
manager 4003 then indicates this consumed label 4000 to its 
associated label switch router 4006 together with informa- 

20 tion about the previously consumed label 4001. The label 
switch router 4006 then "knows" to make a mapping 
between label 4000 and label 4001 for the forward direction. 
Also, the label switch router 4006 "knows" to make a 
mapping between label 4001 and label 4000 in the reverse 

25 direction. In FIG. 19, this means that LSR 4006 sets up a 
label mapping from t2_s2 to t3_s3 in the forward direction 

and from t3_s3 to t2 s2 in the reverse direction. 

The connection manager 4003 then forwards the 200 OK 
message to the next connection manager and incorporates 

30 the consumed label 4000 into this 200 OK message. The 
process then repeats until the 200 OK message reaches the 
originating admission manager. At this stage a complete 
bi-directional communication session is established. 
Full Message Proxy 

35 A fourth method is related to the first method in that an 
ACK message is used to carry label information to set up the 
label mappings. In the first method, the communications 
network is traversed three times by control messages to set 
up a two-way communication session. These three travetsals 

40 take place in series, first the INVITE message, then the 200 
OK message and then the ACK message. The number of 
times the network is traversed in this way affects the set-up 
time for the communications session. In the fourth method, 
the process of propagating the 200 OK message and the 

45 ACK message are concurrent rather than being carried out in 
series which reduces set-up time in some circumstances. 
Also, as in the first method, the forward and reverse paths 
are identical and have the same bandwidth and quality of 
service parameters. 

50 Referring to FIG. 20, the fourth method of setting up a 
two-way communication session is illustrated. The situation 
in FIG. 20 involves the calling party being on the right hand 
side of the figure and the destination or called party being 
connected to an endpoint 5003 at the left hand side of the 

55 figure. An admission manager (not shown) associated with 
the calling party has issued an INVITE message 5006 which 
has reached the destination admission manager 5000 as 
shown. The destination admission manager 5000 then issues 
a 200 OK response 5006 and adds to this a label that it has 

60 consumed for the endpoint 5003. A first connection manager 
5001 receives the 200 OK response 5006 and uses the label 
in that 200 OK response to form a label mapping to the 
endpoint (for use in future by messages travelling in the 
forward direction, from the calling party to the called party). 

65 The label switch router 5004 associated with the first 
connection manager 5001 advertised labels for use on tun- 
nels connected to itself as described above. These labels are 
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cached at the appropriate management nodes, also as 9. A method as claimed in claim 8 wherein said informa- 

described above. This means that the label switch router tion comprises a label for use by a message protocol in order 

5004 also advertised labels for use on tunnels in the reverse to traverse that link. 

direction, from that LSR to the endpoint 5003. The first 10. A method of establishing a bi-directional communi- 
connection manager 5001 is arranged to consume one such s cation session between a first endpoint and a second end- 
label for the reverse direction and add this to an ACK point in a communications network, said method comprising 
message 5007 that it sends back towards the destination the steps of: 

admission manager 5000. The ACK message 5007 also (i) sending a communication from said first endpoint to 

contains a call identifier. said second endpoint to determine a path between said 

When the destination admission manager 5000 receives endpoints; 

ACK message 5007 it checks the call identifier and uses (ii) ^^^^^^ \ j^^ssage along said path in order to set up 

^e label mformaUon to form a label mappmg for the reverse ^ y^^^^ m^p^ing along said path, for use over said 

du-ection . ^ . path in a forward direction; and also concurrently to set 

Meanwhile, the 200 OK message at the first connection „ j i„u^i ;„„ oi««„ c.;^ f^. 

1 L 1 J • .u- . *L up a second label mapping along said path, tor use over 

manager 5001, consumes a label and carnes this on to the *u • j- *• 

next LSR in the path which is a second connection manager 15 said path in a reverse direction. 

5002. In this way the label mapping for the forward path is ^ ^. "^^^^^^^ ^ ^^f^"^^^ claim 10 wherein said 

set up by the 200 OK message. At the same time, ACK communications network comprises nodes mterconnected 

messages sent in the forward direction, as illustrated in FIG, wherem said communications network is 

20 enable a label mapping for the reverse direction to be set configured such that at least some of said communications 

up. In this way the method involves a series of separate 20 li°ks are assigned a label for a forward direction along that 

single hops each establishing a connection using the same link and the same label for a reverse direction along that link, 

set of session parameters. 12. A method as claimed in claim 10 wherein said 

A range of applications are within the scope of the communication session is provided with a specified level of 

invention. These include situations in which it is required to quality of service. 

establish a bi-directional communication session over a 25 13. A method as claimed in claim 10 wherein said 

communications network. For example, transmission of real communications network is an internet protocol communi- 

time internet protocol messages over an MPLS communi- cations network. 

cations network and use of internet protocol communica- 14. A method as claimed in claim 13 wherein said 

tions networks for guaranteed quality of service telephony communication session is suitable for provision of telephony 

sessions. 30 services. 

What is claimed is: 15. A method as claimed in claim 10 wherein said 

1. A method of establishing a bi-directional communica- communications network comprises a plurality of nodes 
tion session between a first endpoint and a second endpoint interconnected by links and wherein said communications 
in a communications network, said method comprising the network is configured such that a plurality of said links are 
steps of: 35 of a specified capacity. 

(i) sending a communication from said second endpoint to 16. A method as claimed in claim 15 wherein nodes which 
said first endpoint to determine a path between said are connected to a link of a specified capacity are arranged 
second and said first endpoints; to advertise information about that link. 

(ii) sending a first message along said path in order to set 17, A method as claimed in claim 16 wherein said 
up a first label mapping along said path, for use over 40 information comprises the source, destination and capacity 
said path in a forward direction; and concurrently ^^nk. 

sending a second message along said path in order to 18. A method as claimed in claim 16 wherein said 

set up a second label mapping along said path, for use information comprises a label for use by a message protocol 

over said path in a reverse direction, in order to traverse that link, 

2. A method as claimed in claim 1 wherein said first and 45 1^. A method of establishing a bi-directional communi- 
second messages are sent along said path in opposite direc- cation session between a first endpoint and a second end- 
tions. point in a communications network, said method comprising 

3. A method as claimed in claim 1 wherein said commu- the steps of: 

nication session is provided with a specified level of quality (i) setting up first label mappings between the endpoints 

of service. so to establish a first uni-directional communication ses- 

4. A method as claimed in claim 1 wherein said commu- sion between the endpoints in a forward direction; 
nications network is an internet protocol communications (ii) setting up second label mappings between the end- 
network, points to establish a second uni-directional communi - 

5. A method as claimed in claim 1 wherein said commu- cation session between the endpoints in a reverse 
nication session is suitable for provision of telephony ser- 55 direction; and 

vices. wherein said steps (i) and (ii) of establishing uni-directional 

6. A method as claimed in claim 1 wherein said commu- communication sessions take place substantially concur- 
nications network comprises a plurality of nodes interoon- rently on the same path, 

nected by links and wherein said communications network 20. A method as claimed in claim 19 wherein said 

is configured such that a plurality of said finks are of a 60 communication session is provided with a specified level of 

specified capacity. quality of service. 

7. A method as claimed in claim 6 wherein nodes which 21. A method as claimed in claim 19 wherein said 
are connected to a link of a specified capacity are arranged communications network is an internet protocol communi- 
to advertise information about that link, cations network. 

8. A method as claimed in claim 7 wherein said informa- 65 22. A method as claimed in claim 21 wherein said 
tion comprises the source, destination and capacity of the communication session is suitable for provision of telephony 
link. services. 
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23. A method as claimed in claim 19 wherein said 
communications network comprises a plurality of nodes 
interconnected by links and wherein said communications 
network is configured such that a plurality of said links are 
of a specified capacity. 

24. A method as claimed in claim 24 wherein said 
communications network includes a plurality of nodes inter- 
connected by links which form a physical layer of said 
communications network and wherein nodes in said physical 
layer which are connected to a link of a specified capacity 
are arranged to advertise information about that link. 

25. A method as claimed in claim 24 wherein said 
information comprises the source, destination and capacity 
of the link. 

26. A method as claimed in claim 24 wherein said 
information comprises a label for use by a message protocol 
in order to traverse that link. 

27. A communications network comprising at least two 
endpoints between which it is desired to establish a 
bi-directional communication session, said communications 
network comprising: 

(i) a determiner arranged to determine a path between said 
second and said first endpoints by sending a commu- 
nication from said second endpoint to said first end- 
point; 

(ii) a processor arranged to send a first message along said 
path in order to set up a first label mapping along said 
path, for use over said path in a forward direction; and 

(iii) a processor arranged to send a second message along 
said path in order to set up a second label mapping 
along said path concurrently with the first label 
mapping, for use over said parti in a reverse direction. 

28. A communications network as claimed in claim 27 
which is an internet protocol communications network. 

29. A communications network as claimed in claim 27 
which is an MPLS communications network. 

30. A communications network comprising at least two 
endpoints between which it is desired to establish a 
bi-directional communication session, said communications 
network comprising: 

(i) a determiner ananged to determine a path between said 
endpoints by sending a communication from said first 
endpoint to said second endpoint; and 

(ii) a processor arranged to send a message along said path 
in order to set up a first label mapping along said path, 
for use over said path in a forward direction; and also 
concurrently to set up a second label mapping along 
said path, for use over said path in a reverse direction. 
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31. A communications network as claimed in claim 30 
which is an internet protocol communications network. 

32. A communications network as claimed in claim 30 
which is an MPLS communications network. 

S 33. A communications network comprising at least two 
endpoints between which it is desired to establish a 
bi-directional communication session, said communications 
network comprising: 

(i) a processor arranged to set up first label mappings 
between the endpoints establish a first uni-directional 
communication session between the endpoints in a 
forward direction; and 

(ii) a second processor arranged to set up second label 
15 mappings between the endpoints establish a second 

uni-directional communication session between the 
endpoints in a reverse direction; and wherein said steps 
(i) and (ii) of establishing uni-directional communica- 
tion sessions take place substantially concurrently on 
the same path. 

34. A computer program stored on a computer readable 
medium said computer program being arranged to control 
said communications network such that: 

25 (i) a communication is sent from said second endpoint to 
said first endpoint to determine a path between said 
second and said first endpoints; 
(u) a first message is sent along said path in order to set 
up a first label mapping along said path, for use over 

30 said path in a forward direction; and concurrently, a 
second message is sent along said path in order to set 
up a second label mapping along said path, for use over 
said path in a reverse direction. 

35. A computer program stored on a computer readable 
3^ medium said computer program being arranged to control 

said communications network such that: 

(i) first label mappings are set up between the endpoints 
to establish first uni-directional communication session 
between the endpoints in a forward direction; 

(ii) second label mappings are set up between the end- 
points to establish a second uni-directional communi- 
cation session between the endpoints in a reverse 
direction; 

45 and wherein said steps (i) and (ii) of establishing uni- 
directional communication sessions take place substantially 
concurrently on the same path. 

* ♦ * ♦ ♦ 
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